NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/14289

Internet Message Format | 1996-08-05 | 6.2 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c,comp.unix.programmer
Subject: Re: Q: '\n' character
Date: 12 Apr 1996 14:26:20 -0700
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <4kj66f$[e-mail]> <4kko80$[e-mail]> <[e-mail]> <4kmdsv$[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <4kmdsv$[e-mail]>, Spasmo <[e-mail]> wrote:
 >Actually from where I'm standing this is the comp.unix.programmer newsgroup.
 >Don't you love crossposting?  It also means that the response was in fact on
 >topic for us, but apparently not for you--the price of crossposting.

Oops, I didn't notice that.

 >: >If this requirement is within  C code where the multiple inputs
 >: >screw up the ability to use pipes, then forgive me for not knowing all
 >: >the facts.
 >: >But,
 >: >The other response using strlen isn't 'wrong'; there are lots of
 >: >ways to skin a cat.
 >
 >: Not if you are being paid by the cat. :) And yes, the strlen() response was
 >: damn wrong. It completely ignored the possiblity that fgets() may return a
 >: string that doesn't have a newline at the end. Just the sort of useless answer
 >: that we don't need on comp.lang.c: incorrect, and is directed at the wrong
 >: question anyway.
 >
 >The strlen() response was right, however it had the possibility of producing
 >undesired effects under certain conditions.  The user wanted a way to remove

So how is it right if it had undesired effects under certain conditions?

 >newlines, and the response above did it.  Of course in the case of a overly

It did not. It removed the last character of the buffer.

 >long line, the response would remove a valid character--however the fact

And of course, *real* UNIX users don't put lines longer than 79 chars into a
textfile anyway...

 >remains that it does remove the newline, and with the addition of some minor
 >code can be made much safer--yet no one has shown the boundary conditions
 >because it's obvious that they can exist, and they are easy to accomodate.

If they are easy to accomodate, why not write it properly in the first place?

Humor me as to why it is necessary to retain a whole string of data just to
then scan through it to find its length to remove the trailining newline, which
was put there by a standard library function that already scanned the
characters once to _find_ the newline in the first place.

 >Also given the application, the conditions that would make the strlen()
 >solution unsafe may not even occur.

Is this representative of your general attitude toward software design, or do
you properly reserve it for writing trivial half-a-pagers?

 >  So, the details of making the solution
 >more robust are left out.

s/more robust/correct/

A robust program is one that deals gracefully with bad input, not one that
manages to avoid failure with valid input. A robust program that doesn't want
to deal with long lines will define these as invalid input, and then somehow
handle their occurence.

 > Perhaps this is an unwarranted assumption, however
 >it was an assumption that was made--at least in my case.  I was one of the
 >folks who suggested the strlen() solution as I use it when needed (with
 >proper checks of course).  And in case you haven't noticed, the strlen() fix
 >is directed at newline stripping which *IS* the right question.  Go back
 >and re-read the original post.

Better yet, why don't I repost it?

Hello everybody,
    Is there a function or some sort of way that I could remove '\n'
charecter form the end of the string. I'm reading from two files, want to
form one line of text and then have it printed out to stdout. I use fgets to
read from the file and I noticed that it appends newline char at the end.
    It is important that two lines of text, one from each file, will be
combined into one and I can't do it because the first string has '\n' added
to it. I'm picky becauuse the output will be used to feed another program and
I'm affraid that not properly formatted input may corrupt the process.
    Any suggestions will be greatly appreciated .. Thanks, Art ...

Tell me again how I answered the wrong problem with my solution, and how you
answered the right one with your non-solution?

 >And yes there are better solutions to the problem.  I like the strchr solution
 >posted by a few folks and will probably use that in preference to
 >strlen(), however it does not take away from the validity of the original

Ah yes. And then there is that fellow who insists that he has never seen a UNIX
system in which it was impossible to do *strchr(string, '\n') = '\0' regardless
of whether there actually is a '\n' character inside ``string''. Simply
brilliant!

 >And using UNIX commands to achieve what you need instead of C is far
 >more elegant, far less typing, far more robust, and far easier than
 >any code you can write.  Get a grip the guy above is discussing using

I agree, but sadly, I had not noticed this was crossposted to a UNIX
newsgroup.

 >UNIX utilities instead of re-inventing the wheel.  And he's got a very

Right, but in comp.lang.c, not everyone is a UNIX user.

 >valid point.  With all the beautiful tools available under UNIX we can
 >get a lot done without having to write any code.  As it stands people
 >jump into a compiler to fix problems that can be better fixed without
 >writing software.  He has a very valid point.  You'd do well to stop
 >babbling and start listening.

I know my UNIX tools well, but I'm not going to push the beautiful beasties
onto Mac, OS/2, Windows or VMS programmers that may be reading comp.lang.c. I
do use UNIX and advocate it and its tools elsewhere, like comp.os.*.advocacy.

Other than that I can _babble_ all I want---I earn that right by posting
correct answers that are tested to work, and get the poor newbie on the right
track, which is what these two newsgroups are for. I never flamed the one who
started this thread with a honest programming question, just the incorrect,
useless help he was getting which is worse than no help at all.

Why should I _listen_ to you? You can't even post a solution to a trivial
problem without overcomplicating it and buggering it up.
--